스팍 커뮤니티에서 몇 번 본 푸념이다.
"스팍으로 폼나게 짜고 싶은데 현실은 잦은 변경과 빠른 피드백 요청때문에 하이브 쿼리로 얽기설기 짜고 퉁치는게 현실이다."
이게 진짜 맞는 평가인지는 내가 평가할 레베루가 아니고. 개쪼렙..
나으 경우는 이렇다.
쪼인이 겁나 많아서 하이브로 보냈더니 겁나 느림. -> 그래서 MR로 짜기로 함. -> 이제 관성적으로 타성적으로 MR로 짬. -> 차츰 귀찮아짐 -> 그 중에 간단한 것은 하이브로 짜는게 편함 -> 하이브 쿼리로 바꾸는 것들이 조금 생김 -> 간만에 태즈로 밀었더니 겁나 빠름 엥? -> 예전 MR도 하이브로 바꿀까..하아..-> 지금 성능도 문제 없고 품질도 문제 없으니 귀찮은데 아몰랑.
여기서 부채는, 명확히 하이브리드로 접근하겠다는 설정없이 단편적인 여건에 따라 어쩌다보니 하이브리드형 ETL이 됐다는 점이다.
그런데 회사 생활하다보면 부채라는 것이 청산의 영역이라기보다는 밸런싱과 컨트롤의 영역이라는 느낌을 받는데, 이것이 주로 핑계나 변명이 될 가능성이 있으므로 보다 공격적으로 부채 청산의 방향성을 갖는쪽이 그나마 낫다라는 거시 나으 오래된 생각이다.
어쩌면,
어차피 설계라는게 항상 망하게 되어 있으므로 변경에 대해 기민하면서도 품질을 유지할 수 있는 구조 혹은 팀(개인) 역량이 중요하며, 이때 아름답고 우아한 와꾸와 구조, 설계에 집착하면 애먼데 에나지를 빨릴 수도 있겠다.
사실 기업 IT의 역사는 안정적이지만 걸레같은 구기술과 힙하지만 어정쩡한 신기술을 계속 마이그레이션 하는 돈으로 부양돼오지 않았능가. 으응??
아.. 차세대...
으응?